docs: Add win64 calling convention, update doc #14349
Conversation
|
I think that may mean that windows defines a calling convention for 64-bit, not that it necessarily uses it. We have it defined because it's an abi that can be used. I don't think that it's the one that windows uses internally at least for kernel32.dll because our I may be wrong though, do you think that the win64 calling convention is the predominant one on win64? |
|
That's the impression I get. I'll grab some win64 binaries tomorrow and pull them apart, until then let's leave this. |
|
Though, if it turns out not to be used, we may want to create an alias for it for uefi, where it is absolutely used. |
|
Win64 defines its own calling convention, and it's the "C" calling convention. On win64, We have explicit notion of win64 calling convention because it may be used outside windows, notably in UEFI specification. (See also #10527 and Booting to Rust) |
|
That explains a lot (The actual usecase was a friend doing some uefi stuff, hence the lack of windows. I'll update the patch to mention win64 in the list. I'm a little suss on using "C" as the example, when it's so nontrivial. |
|
Patch updated. |
…excrichton Wikipedia suggests that windows on x64 has it's own calling convention (Supported by the fact that we implement it) source: http://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions
fix: Fix visibility resolution not respecting parent blocks Fixes rust-lang/rust-analyzer#14047
Since the error kind (`io::ErrorKind::other`) is in the root context, the error message must be found in the root context as well to compute the correct span to remove. Fix rust-lang#14346 changelog: [`io_error_other`]: fix non-applicable suggestion r? @llogiq
Wikipedia suggests that windows on x64 has it's own calling convention (Supported by the fact that we implement it)
source: http://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions